fix(desktop): serialize shared state writes across processes - #718

Avoid recursively deleting a non-file target

When the target path exists as a directory—for example, a workspace already contains .openseek/worktrees.json/—the initial file-to-directory rename fails and this fallback calls remove_if_exists, which recursively deletes directories (desktop/internal/fsx/fsx.mbt lines 103–110). Since workspace and worktree registry writes now use this helper, an attach or worktree mutation can silently erase everything under that directory instead of reporting that the registry path has the wrong type; restrict the fallback to regular files or only the specific Windows replacement error.

Useful? React with 👍 / 👎.

Create the atomic-save temp file without following links

When a workspace already contains a symlink such as .openseek/worktrees.json.tmp pointing to another writable file, creating or updating a worktree reaches this predictable path with CreateOrTruncate, follows the symlink, and truncates the linked file before the rename merely moves the symlink into place. A repository can contain this path before attachment despite the later Git exclusion, so use an exclusively created, unpredictable temporary regular file (and reject links) rather than truncating a fixed name.

Useful? React with 👍 / 👎.

Shield the Windows replacement sequence from cancellation

On Windows, when replacing an existing file reaches this fallback, cancellation after remove completes but before rename completes leaves the target absent; the outer handler then deletes the only completed temp file. This path is reachable from the unshielded legacy archive migration, so cancelling session_list_archived while it rewrites a nonempty remaining list can permanently delete archived_sessions.txt and prevent those sessions from being retried. Protect the remove-and-rename sequence from cancellation, or use a platform replacement operation that cannot expose this state.

Useful? React with 👍 / 👎.

Clean up temporary files when the initial write fails

If write_file creates the random CreateNew file and then raises—for example because the task is cancelled during the write or the filesystem returns ENOSPC—the cleanup handler is never entered because it only wraps commit_temp_file. Each retry therefore leaves another unguessable partial file behind, and failed settings writes can leave credential material in these abandoned files. Wrap the write itself in the same shielded cleanup path.

Useful? React with 👍 / 👎.

Keep legacy migration lock failures best-effort

When archived_sessions.txt is readable but its sidecar cannot be created or locked—for example, the runtime directory became read-only or the filesystem does not support this lock—FileLock::acquire raises here and aborts the entire archived_sessions request. Previously this migration treated filesystem failures as best-effort and still proceeded to list the current archive stores; catch lock-acquisition failures and skip migration so users can still view their archives.

Useful? React with 👍 / 👎.

Refuse symlinks when opening the lock sidecar

When an attached repository already contains .openseek/worktrees.json.lock as a symlink, OpenOrCreate follows it, so a repository can make the desktop create an empty file outside the workspace or lock an attacker-chosen inode. A link to a per-process or concurrently replaced target also lets separate instances hold different locks, defeating the cross-process serialization and permitting the lost registry updates this change is intended to prevent; open the sidecar without following links and verify that it is a regular file.

Useful? React with 👍 / 👎.

Acquire the file lock before deleting the worktree

When the sidecar cannot be opened or locked—for example, the workspace contains the symlink or non-regular .openseek/worktrees.json.lock that open_lock_file deliberately refuses—this acquisition raises only after git worktree remove has already deleted the checkout. The request therefore reports failure while leaving the registry entry behind (and a forced removal may already have discarded changes); acquire the cross-process lock before the initial registry read and destructive Git operation so lock failures leave the worktree untouched.

Useful? React with 👍 / 👎.

Prevent a non-claimant from becoming the primary instance

When two launches overlap during startup, the first process can acquire the heartbeat claim and then be preempted before registering the Proton identity; the second sees Healthy, also enables single_instance, and can register/run first. The claimant then hands off and exits, leaving the surviving primary without a Claim::run heartbeat; if that primary later wedges, subsequent launches see an unlocked heartbeat, classify themselves as Claimed, and hand off to the wedged Proton owner instead of taking the intended fallback path. Ensure only the heartbeat claimant can become the Proton primary, or transfer the claim to whichever process wins the single-instance election.

Useful? React with 👍 / 👎.

Recheck stale heartbeats before bypassing the election

When a machine resumes after being suspended for more than 60 seconds, this wall-clock comparison can run before the existing host's sleeping heartbeat task is scheduled to restamp. A launch in that window is classified as seeing a wedged owner, so main.mbt omits single_instance and starts a competing host even though the original event loop is healthy; confirm that the stamp remains unchanged for another heartbeat interval before bypassing the election.

Useful? React with 👍 / 👎.

Canonicalize the runtime directory used as the identity

When the same existing runtime directory is reached through lexical aliases—for example, a development checkout invoked once through a symlinked parent and once through its physical path—this produces different Proton identities even though both heartbeat paths resolve to the same inode. The processes therefore win separate elections; the second fails claim because the first holds the physical lock, but its on_start handler simply continues without a heartbeat and both hosts run. This is a distinct remaining non-claimant case exposed by the raw path-based identity, so derive the key from the directory's canonical filesystem path.

Useful? React with 👍 / 👎.

Restrict update relaunch consumption to the primary

When a second launch reaches single_instance after the primary has written the shared relaunch marker but before its run loop exits, the second process hands off and returns from app.run(), then continues into take_relaunch_target at main.mbt:199-200. That consumes the primary's marker and opens the new bundle while the primary still owns the instance identity, so the reopened process is handed off and exits; when the primary finally closes, its marker is gone and the updated app is not relaunched. Track whether this process actually became the primary, and only let that process consume the marker.

Useful? React with 👍 / 👎.

Use an atomic Windows replacement for unlocked readers

On Windows, when the first rename cannot overwrite an existing registry or settings file, this fallback removes the target before the second rename. Readers in another process intentionally take no sidecar lock, and registered_workspaces, read_worktrees_unlocked, and load_engine_settings interpret a missing file as an empty registry or default settings, so any read during this window observes false state despite the new atomic-read contract. Cancellation shielding does not hide this gap from other processes; use a platform atomic-replace operation or synchronize those readers.

Useful? React with 👍 / 👎.

Reject primaries that fail to claim the heartbeat

When a launch previously took the stopped-owner path, it omits single_instance; if the old owner exits before on_start, that bypass host can successfully claim and stamp the heartbeat without owning the Proton identity. A later launch then sees the fresh heartbeat, enables single_instance, wins the otherwise-free Proton election, gets None here because the bypass host holds the claim, and nevertheless continues as a second primary with no heartbeat. The fresh evidence after the earlier startup-race fix is this new identity-bypass path; abort or retry/transfer the election when the elected primary cannot claim.

Useful? React with 👍 / 👎.

Gate startup update cleanup on primary status

When another launch is forwarded while the primary is finishing an update, this tail guard does not fully protect the relaunch marker: before app.run() determines that the process is secondary, spawn_host_pumps at lines 171–173 starts SelfUpdate::run, whose startup cleanup_leftovers unconditionally removes the shared relaunch marker (desktop/internal/update/apply.mbt:133-142). The fresh evidence after the earlier marker-consumption fix is this independent startup-cleanup path, which can delete the marker before the primary reaches take_relaunch_target, leaving the updated app swapped on disk but not relaunched; defer that cleanup until on_start confirms this process is primary.

Useful? React with 👍 / 👎.

Wait for the runtime claim before sweeping updates

When a host started through the stopped-owner bypass has claimed the heartbeat but has no Proton single-instance identity, a later launch can win the identity election and reach this hook while hold(dir) is still waiting for that bypass host. Because the cleanup task is spawned independently, it can delete the active host's staging directory or relaunch marker, interrupting an update or preventing the updated bundle from reopening. The fresh evidence after moving cleanup out of the pump is that this final code still runs it before the process has actually acquired the runtime claim; start owner-only cleanup only after that acquisition succeeds.

Useful? React with 👍 / 👎.